A transaction, also called a transactional application, comprises a sequence of operations that changes recoverable resources and data such as a database from one consistent state into another. A transaction processing system guarantees that if a transaction executes some updates against recoverable resources and data, and if a failure occurs before the transaction reaches its normal termination or an interim point of consistency, then those updates will be undone (roll-back). When a new point of consistency has been reached and all updates made by the transaction must be made permanent, the transaction commits.
To fulfill this transaction recovery guarantee, the system must be able to remember across system outages both transactions in progress and their update actions, so that their effect on recoverable data can be properly reflected when the system is restarted. In general the system maintains a log, recorded and maintained by a log manager, of each transaction's progress and changes to the resources and data in order to fulfill the transaction recovery guarantee. The log data, known as log records, can be examined to ensure that either the transaction's committed actions are reflected in the database or were undone. When the log records include actual data, they can also be used to reconstruct data which has been damaged or lost, such as by the failure of a storage device. The log can be thought of as an ever growing sequential file.
The log is permanently stored on stable storage such as a disk file, which remains intact and available across system failures. Log records are first written to temporary, volatile log files buffers in the computer's memory, and then transferred to stable storage at certain times (for example when a transaction is committed).
Locking, supported by a lock manager, is used to control simultaneously executing (i.e. concurrent) transactions' access to shared resources and shared data, and in particular is used to prevent concurrent transactions from inconsistently modifying the same resources and data. Appropriate use of locking can guarantee a transaction that the resource it manipulates and the data it reads is in a consistent state and that the resource and data does not contain uncommitted updates of other transactions.
The recoverable resources and data the transaction is manipulating further may be supported by a resource manager. A resource manager is a subsystem that manages some transactional objects of a certain type. The resource manager typically offers services to applications or other resource managers, which might be available in the overall system. A transactional database system, a transaction queue manager, a transactional session manager and so forth all can act as a resource manager.
A transaction manager administrates, manages and coordinates the flow of the multitude of concurrently processing transactions through the computer system. It orchestrates the commit and undo, i.e. rollback, of transactions as well as the recovery of objects, resource managers, or sites after they fail. Above mentioned consistency requirement for a certain transaction and for all other concurrently processing transaction in the local or distributed transaction system is more accurately expressed as the ACID requirement. Actually ACIDicity is a combination of four different sub-requirements:
atomicity PA0 consistency PA0 isolation PA0 durability
A transactions's changes to the state of the overall system are atomic; either all happen or none happen. These changes include all changes to resources including database changes, messages, actions on transducers and so forth. PA1 A transaction is a correct transformation of the system state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program. PA1 Even though transactions execute concurrently, it appears to each transaction T, that other transactions execute either before T or after T, but not both. PA1 Once a transaction completes successfully and it commits its activities, its changes to the state survive failures, i.e. the state changes became permanent.
Within computer science mechanisms are known to ensure atomicity of global transactions. Details can be found in "J. Gray, A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, San Francisco (Calif.)" for instance. The focus is in so-called Atomic Commit Protocols (ACP) which are synchronous protocols allowing collections of transactions to reach a common consistent transactional outcome i.e. a consistent system state (i.e. either commit or abort). The most wide-spread exploited ACP is the so-called Two-Phase-Commit (2PC) protocol which has been implemented and used many time in a large number of different commercial systems.
Due to its importance the 2PC has been standardized by industry consortia: For instance the procedural variant has been standardized by X/OPEN; its details can be found in "X/OPEN Guide, Distributed transaction Processing Reference Model (Version 2), X/OPEN Company Ltd., U.K. 1993". The object-oriented variant has been standardized by the Object-Management-Group (OMG); its details can be found in "Object Management Group, Object Transaction Services (OTS), OMG Document TC 94.8.4 (1994)". Many standard compliant implementations of the corresponding X/OPEN standard exist and many compliant implementations of the corresponding OMG standard are on its way or have been released recently.
Another known ACP is the so-called Three-Phase-Commit protocol.
The expressive power of a "classic" transaction just consisting of a single atomic activity is quite limited. Many situations exist in which more flexible means of control would be required than classical transaction provide. Especially for real-world applications collections of transactions, called a global transaction, do have to cooperate to achieve a desired processing goal.
For such complex transactions various different models have been developed. Examples are savepoint techniques, nested transactions, chained transactions and so on. An overview of different models can be found for instance in "J. Gray, A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, San Francisco (Calif.)".
All these transaction models do have fundamental problems when considered alone as a vehicle to ensure atomicity for a collection of local or distributed transactions, i.e. for global transactions. The common source for these problems is the difficulty to find a proper balance between atomicity on one side and concurrency on the other side. Preventing to jeopardize the integrity of the overall application on one hand would mean to increase the number of locks held until the end of the global transaction; this would result in a tremendous increase in coordination control effort for assuring atomicity thus creating, especially in distributed processing environments, at the same time performance degradation and a serious loss in concurrency. On the other hand according the current state of the art reductions in the coordination control effort and improvements in performance and concurrency are accompanied by integrity jeopardies.
The chained transaction model for global transactions ensures that the encompassed transactions within the collection of transactions finally will succeed. This result is achieved without assuming that the collection of transactions is encompassed in a 2PC processing thus avoiding certain of above mentioned problems.
According transaction chaining, one can commit one, i.e. a first transaction, releasing all the objects that are no longer needed, and pass the processing context that is still required to the next, i.e. second transaction that is implicitly started. The commitment of the first transaction and the beginning of the next transaction are wrapped together in one atomic operation. This, in turn, means that no other transaction can have seen (or altered) any of the context data that is passed from one transaction to the other.
The disadvantage of the chained transaction model is due to its inherent asynchronous mode of processing: the first transaction just "kicks off" a request of processing of the second transaction without synchronously returning any information whether the second transaction has been started already and without any information on the outcome of its processing. By its very definition of a chained transaction it will make sure that finally all encompassed transactions will receive their service request but not within a guaranteed time frame. Thus, while providing a concept of a unit of work such a unit of work is often in contrast to what users' (both, end users as well as programmers) consider this unit of work to be. Implementing a notion of a unit of work which is more understandable (e.g. having a joint maximum duration) is cumbersome.